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Abstract 


This is a position paper. It documents the author's personal views on how Quality of Service 
(QoS) capabilities ought to be accommodated in Information-Centric Networking (ICN) protocols 
like Content-Centric Networking (CCNx) or Named Data Networking (NDN), which employ flow- 
balanced Interest/Data exchanges and hop-by-hop forwarding state as their fundamental 
machinery. It argues that such protocols demand a substantially different approach to QoS from 
that taken in TCP/IP and proposes specific design patterns to achieve both classification and 
differentiated QoS treatment on both a flow and aggregate basis. It also considers the effect of 
caches in addition to memory, CPU, and link bandwidth as resources that should be subject to 
explicitly unfair resource allocation. The proposed methods are intended to operate purely at the 
network layer, providing the primitives needed to achieve transport- and higher-layer QoS 
objectives. It explicitly excludes any discussion of Quality of Experience (QoE), which can only be 
assessed and controlled at the application layer or above. 


This document is not a product of the IRTF Information-Centric Networking Research Group 
(ICNRG) but has been through formal Last Call and has the support of the participants in the 
research group for publication as an individual submission. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the 
results of Internet-related research and development activities. These results might not be 
suitable for deployment. This RFC represents the individual opinion(s) of one or more members 
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of the Information-Centric Networking Research Group of the Internet Research Task Force 
(IRTF). Documents approved for publication by the IRSG are not candidates for any level of 
Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc9064. 
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This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
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1. Introduction 


The TCP/IP protocol suite used on today's Internet has over 30 years of accumulated research and 
engineering into the provisioning of QoS machinery, employed with varying success in different 
environments. ICN protocols like NDN [NDN] and CCNx [RFC8569] [RFC8609] have an 
accumulated ten years of research and very little deployment. We therefore have the 
opportunity to either recapitulate the approaches taken with TCP/IP (e.g., Intserv [RFC2998] and 
Diffserv [RFC2474]) or design a new architecture and associated mechanisms aligned with the 
properties of ICN protocols, which differ substantially from those of TCP/IP. This position paper 
advocates the latter approach and comprises the author's personal views on how QoS 
capabilities ought to be accommodated in ICN protocols like CCNx or NDN. Specifically, these 
protocols differ in fundamental ways from TCP/IP. The important differences are summarized in 
Table 1: 


TCP/IP CCNx or NDN 
Stateless forwarding Stateful forwarding 
Simple packets Object model with optional caching 
Pure datagram model Request-response model 
Asymmetric routing Symmetric routing 
Independent flow directions Flow balance (see note below) 


Flows grouped by IP prefix and port Flows grouped by name prefix 


End-to-end congestion control Hop-by-hop congestion control 
Table 1: Differences between IP and ICN Relevant to QoS Architecture 
Note: Flow balance is a property of NDN and CCNx that ensures one Interest packet 


provokes a response of no more than one Data packet. Further discussion of the 
relevance of this to QoS can be found in [FLOWBALANCE]. 
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This document proposes specific design patterns to achieve both flow classification and 
differentiated QoS treatment for ICN on both a flow and aggregate basis. It also considers the 
effect of caches in addition to memory, CPU, and link bandwidth as resources that should be 
subject to explicitly unfair resource allocation. The proposed methods are intended to operate 
purely at the network layer, providing the primitives needed to achieve both transport and 
higher-layer QoS objectives. It does not propose detailed protocol machinery to achieve these 
goals; it leaves these to supplementary specifications, such as [FLOWCLASS] and [DNC-QOS-ICN]. 
It explicitly excludes any discussion of QoE, which can only be assessed and controlled at the 
application layer or above. 


Much of this document is derived from presentations the author has given at ICNRG meetings 
over the last few years that are available through the IETF datatracker (see, for example, 
[Oran2018QoSslides]). 


1.1. Applicability Assessment by ICNRG Chairs 


QoS in ICN is an important topic with a huge design space. ICNRG has been discussing different 
specific protocol mechanisms as well as conceptual approaches. This document presents 
architectural considerations for QoS, leveraging ICN properties instead of merely applying IP- 
QoS mechanisms, without defining a specific architecture or specific protocol mechanisms yet. 
However, there is consensus in ICNRG that this document, clarifying the author's views, could 
inspire such work and should hence be published as a position paper. 


2. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


3. Background on Quality of Service in Network Protocols 


Much of this background material is tutorial and can be simply skipped by readers familiar with 
the long and checkered history of quality of service in packet networks. Other parts of it are 
polemical yet serve to illuminate the author's personal biases and technical views. 


All networking systems provide some degree of "quality of service" in that they exhibit nonzero 
utility when offered traffic to carry. In other words, the network is totally useless if it never 
delivers any of the traffic injected by applications. The term QoS is therefore more correctly 
applied in a more restricted sense to describe systems that control the allocation of various 
resources in order to achieve managed unfairness. Absent explicit mechanisms to decide which 
traffic to treat unfairly, most systems try to achieve some form of "fairness" in the allocation of 
resources, optimizing the overall utility delivered to all traffic under the constraint of available 
resources. From this, it should be obvious that you cannot use QoS mechanisms to create or 
otherwise increase resource capacity! In fact, all known QoS schemes have nonzero overhead 
and hence may (albeit slightly) decrease the total resources available to carry user traffic. 
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Further, accumulated experience seems to indicate that QoS is helpful in a fairly narrow range of 
network conditions: 


e If your resources are lightly loaded, you don't need it, as neither congestive loss nor 
substantial queuing delay occurs. 


e If your resources are heavily oversubscribed, it doesn't save you. So many users will be 
unhappy that you are probably not delivering a viable service. 


e Failures can rapidly shift your state from the first above to the second, in which case either: 
o Your QoS machinery cannot respond quickly enough to maintain the advertised service 
quality continuously, or 


o Resource allocations are sufficiently conservative to result in substantial wasted capacity 
under non-failure conditions. 


Nevertheless, though not universally deployed, QoS is advantageous at least for some 
applications and some network environments. Some examples include: 


e Applications with steep utility functions [Shenker2006], such as real-time multimedia 


e Applications with safety-critical operational constraints, such as avionics or industrial 
automation 


e Dedicated or tightly managed networks whose economics depend on strict adherence to 
challenging service level agreements (SLAs) 


Another factor in the design and deployment of QoS is the scalability and scope over which the 
desired service can be achieved. Here there are two major considerations, one technical, the 
other economic/political: 


e Some signaled QoS schemes, such as the Resource reSerVation Protocol (RSVP) [RFC2205], 
maintain state in routers for each flow, which scales linearly with the number of flows. For 
core routers through which pass millions to billions of flows, the memory required is 
infeasible to provide. 


° The Internet is comprised of many minimally cooperating autonomous systems [AS]. There 
are practically no successful examples of QoS deployments crossing the AS boundaries of 
multiple service providers. In almost all cases, this limits the applicability of QoS capabilities 
to be intra-domain. 


This document adopts a narrow definition of QoS as managed unfairness (see note below). 
However, much of the networking literature uses the term more colloquially, applying it to any 
mechanism that improves overall performance. One could use a different, broader definition of 
QoS that encompasses optimizing the allocation of network resources across all offered traffic 
without considering individual users' traffic. A consequence would be the need to cover whether 
(and how) ICN might result in better overall performance than IP under constant resource 
conditions, which is a much broader goal than that attempted here. The chosen narrower scope 
comports with the commonly understood meaning of "QoS" in the research community. Under 
this scope, and under constant resource constraints, the only way to provide traffic 
discrimination is in fact to sacrifice fairness. Readers assuming the broader context will find a 
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large class of proven techniques to be ignored. This is intentional. Among these are seamless 
producer mobility schemes like MAP-Me [Auge2018] and network coding of ICN data as discussed 
in [NWC-CCN-REQS]. 


Note: The term managed unfairness used to explain QoS is generally ascribed to Van 
Jacobson, who in talks in the late 1990s said, "[The problem we are solving is to] 
Give ‘better’ service to some at the expense of giving worse service to others. QoS 
fantasies to the contrary, it's a zero-sum game. In other words, QoS is managed 
unfairness." 


Finally, the relationship between QoS and either accounting or billing is murky. Some schemes 
can accurately account for resource consumption and ascertain to which user to allocate the 
usage. Others cannot. While the choice of mechanism may have important practical economic 
and political consequences for cost and workable business models, this document considers none 
of those things and discusses QoS only in the context of providing managed unfairness. 


For those unfamiliar with ICN protocols, a brief description of how NDN and CCNx operate as a 
packet network is in Section 3.1. Some further background on congestion control for ICN follows 
in Section 3.2. 


3.1. Basics on How ICN Protocols like NDN and CCNx Work 


The following summarizes the salient features of the NDN and CCNx ICN protocols relevant to 
congestion control and QoS. Quite extensive tutorial information may be found in a number of 
places, including material available from [NDNTutorials]. 


In NDN and CCNx, all protocol interactions operate as a two-way handshake. Named content is 
requested by a consumer via an Interest message that is routed hop-by-hop through a series of 
forwarders until it reaches a node that stores the requested data. This can be either the producer 
of the data or a forwarder holding a cached copy of the requested data. The content matching the 
name in the Interest message is returned to the requester over the inverse of the path traversed 
by the corresponding Interest. 


Forwarding in CCNx and NDN is per-packet stateful. Routing information to select next hop(s) for 
an Interest is obtained from a Forwarding Information Base (FIB), which is similar in function to 
the FIB in an IP router except that it holds name prefixes rather than IP address prefixes. 
Conventionally, a Longest Name Prefix Match (LNPM) is used for lookup, although other 
algorithms are possible, including controlled flooding and adaptive learning based on prior 
history. 


Each Interest message leaves a trail of "breadcrumbs" as state in each forwarder. This state, held 
in a data structure known as a Pending Interest Table (PIT), is used to forward the returning Data 
message to the consumer. Since the PIT constitutes per-packet state, it is therefore a large 
consumer of memory resources, especially in forwarders carrying high traffic loads over long 
Round-Trip Time (RTT) paths, and hence plays a substantial role as a QoS-controllable resource 
in ICN forwarders. 
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In addition to its role in forwarding Interest messages and returning the corresponding Data 
messages, an ICN forwarder can also operate as a cache, optionally storing a copy of any Data 
messages it has seen in a local data structure known as a Content Store (CS). Data in the CS may 
be returned in response to a matching Interest rather than forwarding the Interest further 
through the network to the original Producer. Both CCNx and NDN have a variety of ways to 
configure caching, including mechanisms to avoid both cache pollution and cache poisoning 
(these are clearly beyond the scope of this brief introduction). 


3.2. Congestion Control Basics Relevant to ICN 


In any packet network that multiplexes traffic among multiple sources and destinations, 
congestion control is necessary in order to: 


1. Prevent collapse of utility due to overload, where the total offered service declines as load 
increases, perhaps precipitously, rather than increasing or remaining flat. 


2. Avoid starvation of some traffic due to excessive demand by other traffic. 


3. Beyond the basic protections against starvation, achieve "fairness" among competing traffic. 
Two common objective functions are max-min fairness [minmaxfairness] and proportional 
fairness [proportionalfairness], both of which have been implemented and deployed 
successfully on packet networks for many years. 


Before moving on to QoS, it is useful to consider how congestion control works in NDN or CCNx. 
Unlike the IP protocol family, which relies exclusively on end-to-end congestion control (e.g., TCP 
[RFC0793], DCCP [RFC4340], SCTP [RFC4960], and QUIC [RFC9000]), CCNx and NDN can employ 
hop-by-hop congestion control. There is per-Interest/Data state at every hop of the path, and 
therefore outstanding Interests provide information that can be used to optimize resource 
allocation for data returning on the inverse path, such as bandwidth sharing, prioritization, and 
overload control. In current designs, this allocation is often done using Interest counting. By 
accepting one Interest packet from a downstream node, this implicitly provides a guarantee 
(either hard or soft) that there is sufficient bandwidth on the inverse direction of the link to send 
back one Data packet. A number of congestion control schemes have been developed for ICN that 
operate in this fashion, for example, [Wang2013], [Mahdian2016], [Song2018], and 
[Carofiglio2012]. Other schemes, like [Schneider2016], neither count nor police Interests but 
instead monitor queues using AQM (active queue management) to mark returning Data packets 
that have experienced congestion. This later class of schemes is similar to those used on IP in the 
sense that they depend on consumers adequately reducing their rate of Interest injection to 
avoid Data packet drops due to buffer overflow in forwarders. The former class of schemes is 
(arguably) more robust against misbehavior by consumers. 
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Given the stochastic nature of RTTs, and the ubiquity of wireless links and encapsulation tunnels 
with variable bandwidth, a simple scheme that admits Interests only based on a time-invariant 
estimate of the returning link bandwidth will perform poorly. However, two characteristics of 
NDN and CCNx-like protocols can help substantially to improve the accuracy and responsiveness 
of the bandwidth allocation: 


1. RTT is bounded by the inclusion of an Interest Lifetime in each Interest message, which puts 
an upper bound on the RTT uncertainty for any given Interest/Data exchange. If Interest 
Lifetimes are kept reasonably short (a few RTTs), the allocation of local forwarder resources 
do not have to deal with an arbitrarily long tail. One could in fact do a deterministic 
allocation on this basis, but the result would be highly pessimistic. Nevertheless, having a 
cutoff does improve the performance of an optimistic allocation scheme. 


2. A congestion marking scheme like that used in Explicit Congestion Notification (ECN) can be 
used to mark returning Data packets if the inverse link starts experiencing long queue 
occupancy or other congestion indication. Unlike TCP/IP, where the rate adjustment can only 
be done end-to-end, this feedback is usable immediately by the downstream ICN forwarder, 
and the Interest shaping rate is lowered after a single link RTT. This may allow rate 
adjustment schemes that are less pessimistic than the Additive Increase, Multiplicative 
Decrease (AIMD) scheme with .5 multiplier that is commonly used on TCP/IP networks. It 
also allows the rate adjustments to be spread more accurately among the Interest/Data flows 
traversing a link sending congestion signals. 


A useful discussion of these properties and how they demonstrate the advantages of ICN 
approaches to congestion control can be found in [Carofiglio2016]. 


4. What Can We Control to Achieve QoS in ICN? 


QoS is achieved through managed unfairness in the allocation of resources in network elements, 
particularly in the routers that forward ICN packets. Hence, the first-order questions are the 
following: Which resources need to be allocated? How do you ascertain which traffic gets those 
allocations? In the case of CCNx or NDN, the important network element resources are given in 
Table 2: 


Resource ICN Usage 


Communication link capacity buffering for queued packets 


CS capacity to hold cached data 
Forwarder memory for the PIT 
Compute capacity for forwarding packets, including the cost of FIB lookups 


Table 2: ICN-Related Network Element Resources 
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For these resources, any QoS scheme has to specify two things: 


1. How do you create equivalence classes (a.k.a. flows) of traffic to which different QoS 
treatments are applied? 


2. What are the possible treatments and how are those mapped to the resource allocation 
algorithms? 


Two critical facts of life come into play when designing a QoS scheme. First, the number of 
equivalence classes that can be simultaneously tracked in a network element is bounded by both 
memory and processing capacity to do the necessary lookups. One can allow very fine-grained 
equivalence classes but not be able to employ them globally because of scaling limits of core 
routers. That means it is wise to either restrict the range of equivalence classes or allow them to 
be aggregated, trading off accuracy in policing traffic against ability to scale. 


Second, the flexibility of expressible treatments can be tightly constrained by both protocol 
encoding and algorithmic limitations. The ability to encode the treatment requests in the 
protocol can be limited -- as it is for IP where there are only six of the Type of Service (TOS) bits 
available for Diffserv treatments. However, an equal or more important issue is whether there 
are practical traffic policing, queuing, and pacing algorithms that can be combined to support a 
rich set of QoS treatments. 


The two considerations above in combination can easily be substantially more expressive than 
what can be achieved in practice with the available number of queues on real network interfaces 
or the amount of per-packet computation needed to enqueue or dequeue a packet. 


5. How Does This Relate to QoS in TCP/IP? 


TCP/IP has fewer resource types to manage than ICN, and in some cases, the allocation methods 
are simpler, as shown in Table 3: 


Resource IP TCP/IP Usage 
Relevant 

Communication link YES buffering for queued packets 

capacity 

CS capacity NO no CS in IP 

Forwarder memory MAYBE not needed for output-buffered designs (see note 
below) 

Compute capacity YES for forwarding packets, but arguably much 
cheaper than ICN 


Table 3: IP-Related Network Element Resources 
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Note: In an output-buffered design, all packet buffering resources are associated 
with the output interfaces, and neither the receiver interface nor the internal 
forwarding buffers can be over-subscribed. Output-buffered switches or routers are 
common but not universal, as they generally require an internal speedup factor 
where forwarding capacity is greater than the sum of the input capacity of the 
interfaces. 


For these resources, IP has specified three fundamental things, as shown in Table 4: 


What How 
Equivalence subset+prefix match on IP 5-tuple {SA,DA,SP,DP,PT} 
classes SA=Source Address 


DA=Destination Address 
SP=Source Port 
DP=Destination Port 
PT=IP Protocol Type 


Diffserv treatments (very) small number of globally-agreed traffic classes 


Intserv treatments per-flow parameterized Controlled Load and Guaranteed service 
classes 


Table 4: Fundamental Protocol Elements to Achieve QoS for TCP/IP 


Equivalence classes for IP can be pairwise, by matching against both source and destination 
address+port, pure group using only destination address+port, or source-specific multicast with 
source address+port and destination multicast address+ port. 


With Intserv, RSVP [RFC2205] carries two data structures: the Flow Specifier (FLOWSPEC) and 
the Traffic Specifier (TSPEC). The former fulfills the requirement to identify the equivalence class 
to which the QoS being signaled applies. The latter comprises the desired QoS treatment along 
with a description of the dynamic character of the traffic (e.g., average bandwidth and delay, 
peak bandwidth, etc.). Both of these encounter substantial scaling limits, which has meant that 
Intserv has historically been limited to confined topologies, and/or high-value usages, like traffic 
engineering. 


With Diffserv, the protocol encoding (six bits in the TOS field of the IP header) artificially limits 
the number of classes one can specify. These are documented in [RFC4594]. Nonetheless, when 
used with fine-grained equivalence classes, one still runs into limits on the number of queues 
required. 


6. Why Is ICN Different? Can We Do Better? 


While one could adopt an approach to QoS that mirrors the extensive experience with TCP/IP, 
this would, in the author's view, be a mistake. The implementation and deployment of QoS in IP 
networks has been spotty at best. There are, of course, economic and political reasons as well as 
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technical reasons for these mixed results, but there are several architectural choices in ICN that 
make it a potentially much better protocol base to enhance with QoS machinery. This section 
discusses those differences and their consequences. 


6.1. Equivalence Class Capabilities 


First and foremost, hierarchical names are a much richer basis for specifying equivalence classes 
than IP 5-tuples. The IP address (or prefix) can only separate traffic by topology to the granularity 
of hosts and cannot express actual computational instances nor sets of data. Ports give some 
degree of per-instance demultiplexing, but this tends to be both coarse and ephemeral, while 
confounding the demultiplexing function with the assignment of QoS treatments to particular 
subsets of the data. Some degree of finer granularity is possible with IPv6 by exploiting the 
ability to use up to 64 bits of address for classifying traffic. In fact, the Hybrid Information- 
Centric Networking (hICN) project [HICN], while adopting the request-response model of CCNx, 
uses IPv6 addresses as the available namespace, and IPv6 packets (plus "fake" TCP headers) as 
the wire format. 


Nonetheless, the flexibility of tokenized (i.e., strings treated as opaque tokens), variable length, 
hierarchical names allows one to directly associate classes of traffic for QoS purposes with the 
structure of an application namespace. The classification can be as coarse or fine-grained as 
desired by the application. While not always the case, there is typically a straightforward 
association between how objects are named and how they are grouped together for common 
treatment. Examples abound; a number can be conveniently found in [FLOWCLASS]. 


6.2. Topology Interactions with QoS 


In ICN, QoS is not pre-bound to network topology since names are non-topological, unlike unicast 
IP addresses. This allows QoS to be applied to multi-destination and multipath environments ina 
straightforward manner, rather than requiring either multicast with coarse class-based 
scheduling or complex signaling like that in RSVP Traffic Engineering (RSVP-TE) [RFC3209] that is 
needed to make point-to-multipoint Multiprotocol Label Switching (MPLS) work. 


Because of IP's stateless forwarding model, complicated by the ubiquity of asymmetric routes, 
any flow-based QoS requires state that is decoupled from the actual arrival of traffic and hence 
must be maintained, at least as soft state, even during quiescent periods. Intserv, for example, 
requires flow signaling on the order of Omumber of flows). ICN, even worst case, requires order 
of O(number of active Interest/Data exchanges), since state can be instantiated on arrival of an 
Interest and removed (perhaps lazily) once the data has been returned. 


6.3. Specification of QoS Treatments 


Unlike Intserv, Diffserv eschews signaling in favor of class-based configuration of resources and 
queues in network elements. However, Diffserv limits traffic treatments to a few bits taken from 
the TOS field of IP. No such wire encoding limitations exist for NDN or CCNx, as the protocol is 
completely TLV (Type-Length-Value) based, and one (or even more than one) new field can be 
easily defined to carry QoS treatment information. 


Oran Informational Page 11 


RFC 9064 Thoughts on ICN QoS Architecture June 2021 


Therefore, there are greenfield possibilities for more powerful QoS treatment options in ICN. For 
example, IP has no way to express a QoS treatment like "try hard to deliver reliably, even at the 
expense of delay or bandwidth". Such a QoS treatment for ICN could invoke native ICN 
mechanisms, none of which are present in IP, such as the following: 


e Retransmitting in-network in response to hop-by-hop errors returned from upstream 
forwarders 


e Trying multiple paths to multiple content sources either in parallel or serially 


e Assigning higher precedence for short-term caching to recover from downstream (see note 
below) errors 


e Coordinating cache utilization with forwarding resources 


Note: Downstream refers to the direction Data messages flow toward the consumer 
(the issuer of Interests). Conversely, Upstream refers to the direction Interests flow 
toward the producer of data. 


Such mechanisms are typically described in NDN and CCNx as forwarding strategies. However, 
there is little or no guidance for which application actions or protocol machinery a forwarder 
should use to select the appropriate forwarding strategy for arriving Interest messages. See 
[BenAbraham2018] for an investigation of these issues. Associating forwarding strategies with 
the equivalence classes and QoS treatments directly can make them more accessible and useful 
to implement and deploy. 


Stateless forwarding and asymmetric routing in IP limits available state/feedback to manage link 
resources. In contrast, NDN or CCNx forwarding allows all link resource allocation to occur as 
part of Interest forwarding, potentially simplifying things considerably. In particular, with 
symmetric routing, producers have no control over the paths their Data packets traverse; hence, 
any QoS treatments intended to influence routing paths from producer to consumer will have no 
effect. 


One complication in the handling of ICN QoS treatments is not present in IP and hence worth 
mentioning. CCNx and NDN both perform Interest aggregation (see Section 2.4.2 of [RFC8569)). If 
an Interest arrives matching an existing PIT entry, but with a different QoS treatment from an 
Interest already forwarded, it can be tricky to decide whether to aggregate the Interest or 
forward it, and how to keep track of the differing QoS treatments for the two Interests. 
Exploration of the details surrounding these situations is beyond the scope of this document; 
further discussion can be found for the general case of flow balance and congestion control in 
[FLOWBALANCE] and specifically for QoS treatments in [DNC-QOS-ICN]. 


6.4. ICN Forwarding Semantics Effect on QoS 


IP has three forwarding semantics, with different QoS needs (Unicast, Anycast, Multicast). ICN 

has the single forwarding semantic, so any QoS machinery can be uniformly applied across any 
request/response invocation. This applies whether the forwarder employs dynamic destination 
routing, multi-destination forwarding with next hops tried serially, multi-destination with next 
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hops used in parallel, or even localized flooding (e.g., directly on Layer 2 multicast mechanisms). 
Additionally, the pull-based model of ICN avoids a number of thorny multicast QoS problems that 
IP has (see [Wang2000], [RFC3170], and [Tseng2003]). 


The Multi-destination/multipath forwarding model in ICN changes resource allocation needs in a 
fairly deep way. IP treats all endpoints as open-loop packet sources, whereas NDN and CCNx have 
strong asymmetry between producers and consumers as packet sources. 


6.5. QoS Interactions with Caching 


IP has no caching in routers, whereas ICN needs ways to allocate cache resources. Treatments to 
control caching operation are unlikely to look much like the treatments used to control link 
resources. NDN and CCNx already have useful cache control directives associated with Data 
messages. The CCNx controls include the following: 


ExpiryTime: time after which a cached Content Object is considered expired and MUST no 
longer be used to respond to an Interest from a cache. 


Recommended Cache Time: time after which the publisher considers the Content Object to be 
of low value to cache. 


See [RFC8569] for the formal definitions. 


ICN flow classifiers, such as those in [FLOWCLASS] can be used to achieve soft or hard 
partitioning (see note below) of cache resources in the CS of an ICN forwarder. For example, 
cached content for a given equivalence class can be considered fate shared in a cache whereby 
objects from the same equivalence class can be purged as a group rather than individually. This 
can recover cache space more quickly and at lower overhead than pure per-object replacement 
when a cache is under extreme pressure and in danger of thrashing. In addition, since the 
forwarder remembers the QoS treatment for each pending Interest in its PIT, the above cache 
controls can be augmented by policy to prefer retention of cached content for some equivalence 
classes as part of the cache replacement algorithm. 


Note: With hard partitioning, there are dedicated cache resources for each 
equivalence class (or enumerated list of equivalence classes). With soft partitioning, 
resources are at least partly shared among the (sets of) equivalence classes of traffic. 


7. Strawman Principles for an ICN QoS Architecture 


Based on the observations made in the earlier sections, this summary section captures the 
author's ideas for clear and actionable architectural principles for incorporating QoS machinery 
into ICN protocols like NDN and CCNx. Hopefully, they can guide further work and focus effort on 
portions of the giant design space for QoS that have the best trade-offs in terms of flexibility, 
simplicity, and deployability. 
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Define equivalence classes using the name hierarchy rather than creating an independent 
traffic class definition. This directly associates the specification of equivalence classes of traffic 
with the structure of the application namespace. It can allow hierarchical decomposition of 
equivalence classes in a natural way because of the way hierarchical ICN names are constructed. 
Two practical mechanisms are presented in [FLOWCLASS] with different trade-offs between 
security and the ability to aggregate flows. Either the prefix-based mechanism (the equivalence 
class component count (EC3) scheme) or the explicit name component-based mechanism (the 
equivalence class name component type (ECNCT) scheme), or both, could be adopted as the part 
of the QoS architecture for defining equivalence classes. 


Put consumers in control of link and forwarding resource allocation. Base all link buffering 
and forwarding (both memory and CPU) resource allocations on Interest arrivals. This is 
attractive because it provides early congestion feedback to consumers and allows scheduling the 
reverse link direction for carrying the matching data in advance. It makes enforcement of QoS 
treatments a single-ended (i.e., at the consumer) rather than a double-ended problem and can 
avoid wasting resources on fetching data that will be dropped when it arrives at a bottleneck 
link. 


Allow producers to influence the allocation of cache resources. Producers want to affect 
caching decisions in order to do the following: 


° Shed load by having Interests served by CSes in forwarders before they reach the producer 
itself 


e Survive transient producer reachability or link outages close to the producer 


For caching to be effective, individual Data objects in an equivalence class need to have similar 
treatment; otherwise, well-known cache-thrashing pathologies due to self-interference emerge. 
Producers have the most direct control over caching policies through the caching directives in 
Data messages. It therefore makes sense to put the producer, rather than the consumer or 
network operator, in charge of specifying these equivalence classes. 


See [FLOWCLASS] for specific mechanisms to achieve this. 


Allow consumers to influence the allocation of cache resources. Consumers want to affect 
caching decisions in order to do the following: 


e Reduce latency for retrieving data 
e Survive transient outages of either a producer or links close to the consumer 


Consumers can have indirect control over caching by specifying QoS treatments in their 
Interests. Consider the following potential QoS treatments by consumers that can drive caching 
policies: 


e A QoS treatment requesting better robustness against transient disconnection can be used by 
a forwarder close to the consumer (or downstream of an unreliable link) to preferentially 
cache the corresponding data. 
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e Conversely, a QoS treatment together with, or in addition to, a request for short latency 
indicating that the forwarder should only pay attention to the caching preferences of the 
producer because caching requested data would be ineffective (i.e., new data will be 
requested shortly). 

e A QoS treatment indicating that a mobile consumer will likely incur a mobility event within 
an RTT (or a few RTTs). Such a treatment would allow a mobile network operator to 
preferentially cache the data at a forwarder positioned at a join point or rendezvous point of 
their topology. 


Give network operators the ability to match customer SLAs to cache resource availability. 
Network operators, whether closely tied administratively to producer or consumer, or 
constituting an independent transit administration, provide the storage resources in the ICN 
forwarders. Therefore, they are the ultimate arbiters of how the cache resources are managed. In 
addition to any local policies they may enforce, the cache behavior from the QoS standpoint 
emerges from the mapping of producer-specified equivalence classes onto cache space 
availability, including whether cache entries are treated individually or fate-shared. Forwarders 
also determine the mapping of consumer-specified QoS treatments to the precedence used for 
retaining Data objects in the cache. 


Besides utilizing cache resources to meet the QoS goals of individual producers and consumers, 
network operators also want to manage their cache resources in order to do the following: 


e Ameliorate congestion hotspots by reducing load converging on producers they host on their 
network 

e Improve Interest satisfaction rates by utilizing caches as short-term retransmission buffers 
to recover from transient producer reachability problems, link errors, or link outages 

e Improve both latency and reliability in environments when consumers are mobile in the 
operator's topology 


Rethink how to specify traffic treatments -- don't just copy Diffserv. Some of the Diffserv 
classes may form a good starting point, as their mappings onto queuing algorithms for managing 
link buffering are well understood. However, Diffserv alone does not capture more complex QoS 
treatments, such as: 


e Trading off latency against reliability 


e Trading off resource usage against delivery probability through controlled flooding or other 
forwarding mechanisms 


e Allocating resources based on rich TSPEC-like traffic descriptions that appear in signaled QoS 
schemes like Intserv 


Here are some examples: 


e A "burst" treatment, where an initial Interest gives an aggregate data size to request 
allocation of link capacity for a large burst of Interest/Data exchanges. The Interest can be 
rejected at any hop if the resources are not available. Such a treatment can also 
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accommodate Data implosion produced by the discovery procedures of management 
protocols like [CCNINFO]. 


e A "reliable" treatment, which affects preference for allocation of PIT space for the Interest 
and CS space for the Data in order to improve the robustness of IoT data delivery in a 
constrained environment, as is described in [IOTQOS]. 


e A "search" treatment, which, within the specified Interest Lifetime, tries many paths either in 
parallel or serially to potentially many content sources, to maximize the probability that the 
requested item will be found. This is done at the expense of the extra bandwidth of both 
forwarding Interests and receiving multiple responses upstream of an aggregation point. 
The treatment can encode a value expressing trade-offs like breadth-first versus depth-first 
search, and bounds on the total resource expenditure. Such a treatment would be useful for 
instrumentation protocols like [ICNTRACEROUTE]. 


As an aside, loose latency control (on the order of seconds or tens of milliseconds as 
opposed milliseconds or microseconds) can be achieved by bounding Interest 
Lifetime as long as this lifetime machinery is not also used as an application 
mechanism to provide subscriptions or to establish path traces for producer 
mobility. See [Krol2018] for a discussion of the network versus application timescale 
issues in ICN protocols. 


7.1. Can Intserv-Like Traffic Control in ICN Provide Richer QoS Semantics? 


Basic QoS treatments such as those summarized above may not be adequate to cover the whole 
range of application utility functions and deployment environments we expect for ICN. While it 
is true that one does not necessarily need a separate signaling protocol like RSVP given the state 
carried in the ICN data plane by forwarders, simple QoS treatments applied per Interest/Data 
exchanges lack some potentially important capabilities. Intserv's richer QoS capabilities may be 
of value, especially if they can be provided in ICN at lower complexity and protocol overhead 
than Intserv plus RSVP. 


There are three key capabilities missing from Diffserv-like QoS treatments, no matter how 
sophisticated they may be in describing the desired treatment for a given equivalence class of 
traffic. Intserv-like QoS provides all of these: 


1. The ability to describe traffic flows in a mathematically meaningful way. This is done 
through parameters like average rate, peak rate, and maximum burst size. The parameters 
are encapsulated in a data structure called a "TSPEC", which can be placed in whatever 
protocol needs the information (in the case of TCP/IP Intserv, this is RSVP). 


2. The ability to perform admission control, where the element requesting the QoS treatment 
can know before introducing traffic whether the network elements have agreed to provide 
the requested traffic treatment. An important side effect of providing this assurance is that 
the network elements install state that allows the forwarding and queuing machinery to 
police and shape the traffic in a way that provides a sufficient degree of isolation from the 
dynamic behavior of other traffic. Depending on the admission-control mechanism, it may or 
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may not be possible to explicitly release that state when the application no longer needs the 
QoS treatment. 


3. The ability to specify the permissible degree of divergence in the actual traffic handling 
from the requested handling. Intserv provides two choices here: the controlled load service 
and the guaranteed service. The former allows stochastic deviation equivalent to what one 
would experience on an unloaded path of a packet network. The latter conforms to the 
TSPEC deterministically, at the obvious expense of demanding extremely conservative 
resource allocation. 


Given the limited applicability of these capabilities in today's Internet, the author does not take 
any position as to whether any of these Intserv-like capabilities are needed for ICN to be 
successful. However, a few things seem important to consider. The following paragraphs 
speculate about the consequences of incorporating these features into the CCNx or NDN protocol 
architectures. 


Superficially, it would be quite straightforward to accommodate Intserv-equivalent traffic 
descriptions in CCNx or NDN. One could define a new TLV for the Interest message to carry a 
TSPEC. A forwarder encountering this, together with a QoS treatment request (e.g., as proposed 
in Section 6.3), could associate the traffic specification with the corresponding equivalence class 
derived from the name in the Interest. This would allow the forwarder to create state that not 
only would apply to the returning Data for that Interest when being queued on the downstream 
interface but also be maintained as soft state across multiple Interest/Data exchanges to drive 
policing and shaping algorithms at per-flow granularity. The cost in Interest message overhead 
would be modest; however, the complications associated with managing different traffic 
specifications in different Interests for the same equivalence class might be substantial. Of 
course, all the scalability considerations with maintaining per-flow state also come into play. 


Similarly, it would be equally straightforward to have a way to express the degree of divergence 
capability that Intserv provides through its controlled load and guaranteed service definitions. 
This could either be packaged with the traffic specification or encoded separately. 


In contrast to the above, performing admission control for ICN flows is likely to be just as 
heavyweight as it is with IP using RSVP. The dynamic multipath, multi-destination forwarding 
model of ICN makes performing admission control particularly tricky. Just to illustrate: 


e Forwarding next-hop selection is not confined to single paths (or a few ECMP equivalent 
paths) as it is with IP, making it difficult to know where to install state in advance of the 
arrival of an Interest to forward. 

e As with point-to-multipoint complexities when using RSVP for MPLS-TE, state has to be 
installed to multiple producers over multiple paths before an admission-control algorithm 
can commit the resources and say "yes" to a consumer needing admission-control 
capabilities. 

e Knowing when to remove admission-control state is difficult in the absence of a heavyweight 
resource reservation protocol. Soft state timeout may or may not be an adequate answer. 
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Despite the challenges above, it may be possible to craft an admission-control scheme for ICN 
that achieves the desired QoS goals of applications without the invention and deployment of a 
complex, separate admission-control signaling protocol. There have been designs in earlier 
network architectures that were capable of performing admission control piggybacked on packet 
transmission. 


The earliest example the author is aware of is [Autonet]. 


Such a scheme might have the following general shape (warning: serious hand-waving follows!): 


e In addition to a QoS treatment and a traffic specification, an Interest requesting admission 
for the corresponding equivalence class would indicate this via a new TLV. It would also 
need to do the following: (a) indicate an expiration time after which any reserved resources 
can be released, and (b) indicate that caches be bypassed, so that the admission-control 
request arrives at a bona fide producer. 


Each forwarder processing the Interest would check for resource availability. If the 
resources are not available, or the requested service is not feasible, the forwarder would 
reject the Interest with an admission-control failure. If resources are available, the 
forwarder would record the traffic specification as described above and forward the 
Interest. 


If the Interest successfully arrives at a producer, the producer would return the requested 
Data. 


Upon receiving the matching Data message and if the resources are still available, each on- 
path forwarder would allocate resources and would mark the admission control TLV as 
"provisionally approved". Conversely, if the resource reservation fails, the admission control 
would be marked "failed", although the Data would still be passed downstream. 


Upon the Data message arrival, the consumer would know if admission succeeded or not, 
and subsequent Interests could rely on the QoS state being in place until either some failure 
occurs, or a topology or other forwarding change alters the forwarding path. To deal with 
this, additional machinery is needed to ensure subsequent Interests for an admitted flow 
either follow that path or an error is reported. One possibility (also useful in many other 
contexts), is to employ a Path Steering mechanism, such as the one described in 
[Moiseenko2017]. 


8. IANA Considerations 


This document has no IANA actions. 


9. Security Considerations 


There are a few ways in which QoS for ICN interacts with security and privacy issues. Since QoS 
addresses relationships among traffic rather than the inherent characteristics of traffic, it neither 
enhances nor degrades the security and privacy properties of the data being carried, as long as 
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the machinery does not alter or otherwise compromise the basic security properties of the 
associated protocols. The QoS approaches advocated here for ICN can serve to amplify existing 
threats to network traffic. However: 


e An attacker able to manipulate the QoS treatments of traffic can mount a more focused (and 
potentially more effective) denial-of-service attack by suppressing performance on traffic the 
attacker is targeting. Since the architecture here assumes QoS treatments are manipulatable 
hop-by-hop, any on-path adversary can wreak havoc. Note, however, that in basic ICN, an 
on-path attacker can do this and more by dropping, delaying, or misrouting traffic 
independent of any particular QoS machinery in use. 

e When equivalence classes of traffic are explicitly revealed via either names or other fields in 
packets, an attacker has yet one more handle to use to discover linkability of multiple 
requests. 
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